[Kotlin-client] fix kotlin code client generator for oneOf with allOf by bykakashka · Pull Request #24163 · OpenAPITools/openapi-generator

bykakashka · 2026-06-30T09:27:52Z

Removed children params from parent model in case of oneOf + allOf usage. Fixes #24164

PR checklist

Read the contribution guidelines.
Run the following to build the project and update samples:
```
./mvnw clean package || exit
./bin/generate-samples.sh ./bin/configs/*.yaml || exit
./bin/utils/export_docs_generators.sh || exit
```
(For Windows users, please run the script in WSL)
Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Summary by cubic

Fixes Kotlin client codegen for polymorphic oneOf + allOf with discriminators by preventing child properties from merging into parent models. Keeps oneOf/anyOf form-data parameters generating fields correctly across jackson, moshi, gson, and kotlinx_serialization.

Bug Fixes
- Enable skipOneOfPropertyMergeInParent = true in KotlinClientCodegen (constructor) for all serializers; move flag from AbstractKotlinCodegen and decouple from supportsInheritance.
- Simplify DefaultCodegen: treat oneOf/anyOf as alternatives when the flag is on (no child-property merge into parents even with discriminators); add a flattening path so form-data oneOf/anyOf params still produce individual fields; update ProtobufSchemaCodegen override to the new addProperties signature.
- Add parameterized tests for all serializers: plain oneOf wrapper, oneOf with discriminator (no leak), plain allOf (inheritance preserved), allOf with discriminator (no leak), and mixed allOf/oneOf with discriminator.
- Regenerate samples and docs; minor TypeScript Fetch guard tightening.

^{Written for commit d9e1116. Summary will update on new commits.}

cubic-dev-ai

3 issues found across 4 files

_{Reply with feedback, questions, or to request a fix.

Re-trigger cubic}

…Inheritance - Remove supportsInheritance gate from the non-merge branch condition to avoid silently re-enabling child-property merging for generators using alternative polymorphism strategies - Move skipOneOfPropertyMergeInParent flag from AbstractKotlinCodegen to KotlinClientCodegen (more specific scope) - Fix test assertions to check correct model paths

cubic-dev-ai

1 issue found across 4 files (changes from recent commits).

Prompt for AI agents (unresolved issues)


Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/KotlinClientCodegen.java">

<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/KotlinClientCodegen.java:311">
P2: Setting `skipOneOfPropertyMergeInParent = true` unconditionally in the KotlinClientCodegen constructor affects all oneOf/anyOf schemas, not just the oneOf+allOf case described in the PR. In `DefaultCodegen.addProperties()`, this flag prevents merging oneOf AND anyOf child properties into parent models globally. Since KotlinClientCodegen only supports oneOf/anyOf wrappers for `jvm-retrofit2` with `gson`/`kotlinx_serialization`, and the default is `jvm-okhttp4` with `moshi`, plain oneOf/anyOf schemas under default or unsupported configurations may lose child properties with no wrapper fallback. Consider scoping this flag to the specific oneOf+allOf/discriminator case or to library/serialization combinations that provide wrapper support.</violation>
</file>

_{Reply with feedback, questions, or to request a fix.

Re-trigger cubic}

cubic-dev-ai · 2026-06-30T10:31:16Z

        cliOptions.add(CliOption.newBoolean(USE_JACKSON_3,
            "Use Jackson 3 dependencies (tools.jackson package). Not yet supported for kotlin-client; reserved for future use."));
+
+        skipOneOfPropertyMergeInParent = true;


P2: Setting skipOneOfPropertyMergeInParent = true unconditionally in the KotlinClientCodegen constructor affects all oneOf/anyOf schemas, not just the oneOf+allOf case described in the PR. In DefaultCodegen.addProperties(), this flag prevents merging oneOf AND anyOf child properties into parent models globally. Since KotlinClientCodegen only supports oneOf/anyOf wrappers for jvm-retrofit2 with gson/kotlinx_serialization, and the default is jvm-okhttp4 with moshi, plain oneOf/anyOf schemas under default or unsupported configurations may lose child properties with no wrapper fallback. Consider scoping this flag to the specific oneOf+allOf/discriminator case or to library/serialization combinations that provide wrapper support.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/KotlinClientCodegen.java, line 311: <comment>Setting `skipOneOfPropertyMergeInParent = true` unconditionally in the KotlinClientCodegen constructor affects all oneOf/anyOf schemas, not just the oneOf+allOf case described in the PR. In `DefaultCodegen.addProperties()`, this flag prevents merging oneOf AND anyOf child properties into parent models globally. Since KotlinClientCodegen only supports oneOf/anyOf wrappers for `jvm-retrofit2` with `gson`/`kotlinx_serialization`, and the default is `jvm-okhttp4` with `moshi`, plain oneOf/anyOf schemas under default or unsupported configurations may lose child properties with no wrapper fallback. Consider scoping this flag to the specific oneOf+allOf/discriminator case or to library/serialization combinations that provide wrapper support.</comment> <file context> @@ -307,6 +307,8 @@ public KotlinClientCodegen() { cliOptions.add(CliOption.newBoolean(USE_JACKSON_3, "Use Jackson 3 dependencies (tools.jackson package). Not yet supported for kotlin-client; reserved for future use.")); + + skipOneOfPropertyMergeInParent = true; } </file context>

The bug affects all serialization libraries equally. Without the fix, moshi, gson, and kotlinx_serialization all produce identical broken output — fat parent interfaces with leaked child properties and sibling contamination.

Plain oneOf without discriminator is NOT affected. These schemas generate a data class wrapper (not an interface), and addProperties() merging is correct — the wrapper IS supposed to contain all variant properties as a union type. Tested and confirmed.

Plain allOf without discriminator is NOT affected. Standard inheritance works identically with and without the fix.

Added 16 new parameterized tests covering all 4 patterns (plain oneOf, oneOf+discriminator, plain allOf, allOf+discriminator) × all 4 serialization libraries (jackson, moshi, gson, kotlinx_serialization) — all pass. The flag is safe to set unconditionally at the KotlinClientCodegen level.

cubic-dev-ai

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)


Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/KotlinClientCodegen.java">

<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/KotlinClientCodegen.java:311">
P2: Setting `skipOneOfPropertyMergeInParent = true` unconditionally in the KotlinClientCodegen constructor affects all oneOf/anyOf schemas, not just the oneOf+allOf case described in the PR. In `DefaultCodegen.addProperties()`, this flag prevents merging oneOf AND anyOf child properties into parent models globally. Since KotlinClientCodegen only supports oneOf/anyOf wrappers for `jvm-retrofit2` with `gson`/`kotlinx_serialization`, and the default is `jvm-okhttp4` with `moshi`, plain oneOf/anyOf schemas under default or unsupported configurations may lose child properties with no wrapper fallback. Consider scoping this flag to the specific oneOf+allOf/discriminator case or to library/serialization combinations that provide wrapper support.</violation>
</file>

_{Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic}

Parameterize existing polymorphism tests to run against all 4 Kotlin serialization libraries (jackson, moshi, gson, kotlinx_serialization), covering: - Plain oneOf without discriminator (wrapper model) - oneOf with discriminator (no child property leaking) - Plain allOf without discriminator (inheritance preserved) - allOf with discriminator (no child property leaking) Simplify DefaultCodegen guards: remove discriminator-scoping from addProperties() since the flag is set at the KotlinClientCodegen level for all serialization libraries. Move flag from Jackson-only processOpts back to constructor — the bug affects all serializers equally and tests confirm the fix is safe across all configurations.

wing328 · 2026-07-10T13:22:19Z

please follow step 3 to update the samples

cubic-dev-ai

All reported issues were addressed across 12 files (changes from recent commits).

_{Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic}

…ipOneOfPropertyMergeInParent. Update samples and docs

bykakashka · 2026-07-11T09:52:15Z

please follow step 3 to update the samples

updated samples & fixed generation for form-data

Mattias-Sehlstedt · 2026-07-14T14:21:45Z

Rather than extending the behavior of the DefaultCodegen would it not make more sense to have the Kotlin generator interpret the Codegen structure differently for Interface and Model?

So that the Codegen is always populated with parameters that might be needed in order to express different hierarchies, but different cases read these differently. I.e., Interface is a view that only reads X and Model reads Y.

the Java client generator has long only generated a basic interface with only the discriminator property, but people have been asking if it can be extended with more shared variables. Making it so that the Codegen model better captures where it got the properties from would enable both of these scenarios to work much better, and we would have a shared DefaultCodegen that each language then used to the extend that the language allows?

Having a boolean seems unnatural to me, and especially the fact that we have to force it to true in certain places. It feels more natural to have "ignore properties Z since we are building a serialization interface" in the Kotlin generator.

Could you share the generator settings that you use? I can see that there for example exist generateOneOfAnyOfWrappers: true. To me it seems like the basic interface definition is just a unsuited for being part of data_class.mustache, and that there are already some different ways that people have tried to tackle that?

bykakashka · 2026-07-16T09:03:57Z

Rather than extending the behavior of the DefaultCodegen would it not make more sense to have the Kotlin generator interpret the Codegen structure differently for Interface and Model?

kinda yes, but the main issue is 'updateModelForComposedSchema' which adds all the children params into CodegenModel.vars. WWe can add a new field smth like 'childerVars' and use it in lang-specific mustache/generators if needed, to replicate current output. But I'm not so confident in refactoring this functionality for all languages. I can try tho

Could you share the generator settings that you use?

default settings as in testOneOfAllOfDiscriminatorInheritancePropertiesNotLeakedToParent test

Mattias-Sehlstedt · 2026-07-16T10:59:14Z

I believe a part of the issue too is that your specification is using a structure that is generally harder than necessary to interpret and reason about. This since you have infinite recursion with the oneOf -> allOf -> oneOf -> allOf -> ...

I personally always do either an allOf inheritance for the polymorphic structure or the oneOf. This both to integrate well with tooling for code generation but also to get a correct visual presentation (e.g., in swagger-ui). This is currently presented in swagger-ui as:

If you are using springdoc-openapi to generate the specification yourself then I should be able to provide some way of handling this better.

You can see the difference between the two ways in the OAS examples, with oneOf and allOf.

bykakashka · 2026-07-17T16:11:56Z

hm, my bad. somehow I missed the diff between my old openapi spec and spring generated one ... I'll play with spring openapi generator, and will close this MR/ticket
thanks!

[Kotlin-client] fix kotlin code client generator for oneOf with allOf

5290a94

bykakashka mentioned this pull request Jun 30, 2026

[BUG] [Kotlin] Client generator produces 'fat' classes in case of oneOf with allOf #24164

Closed

6 tasks

bykakashka marked this pull request as ready for review June 30, 2026 09:30

cubic-dev-ai Bot reviewed Jun 30, 2026

View reviewed changes

Comment thread ...pi-generator/src/test/java/org/openapitools/codegen/kotlin/KotlinClientCodegenModelTest.java

bykakashka force-pushed the fix/kotlin_client_allOf-oneOf branch from 91c4667 to 646e880 Compare June 30, 2026 13:08

update the samples

081046d

cubic-dev-ai Bot reviewed Jul 11, 2026

View reviewed changes

Comment thread ...pi/kotlin-model-prefix-type-mappings/src/main/kotlin/org/openapitools/client/apis/FormApi.kt Outdated

Comment thread ...es/client/echo_api/kotlin-jvm-okhttp/src/main/kotlin/org/openapitools/client/apis/FormApi.kt Outdated

[Kotlin-client] fix form-data model generation for generation with sk…

84e881f

…ipOneOfPropertyMergeInParent. Update samples and docs

[Kotlin-client] remove leftover from other change

d9e1116

bykakashka closed this Jul 17, 2026

Uh oh!

Uh oh!

Conversation

bykakashka commented Jun 30, 2026 • edited by cubic-dev-ai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR checklist

Summary by cubic

Uh oh!

cubic-dev-ai Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot Jun 30, 2026

Choose a reason for hiding this comment

Uh oh!

bykakashka Jun 30, 2026

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

wing328 commented Jul 10, 2026

Uh oh!

cubic-dev-ai Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

bykakashka commented Jul 11, 2026

Uh oh!

Mattias-Sehlstedt commented Jul 14, 2026

Uh oh!

bykakashka commented Jul 16, 2026

Uh oh!

Mattias-Sehlstedt commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bykakashka commented Jul 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

bykakashka commented Jun 30, 2026 •

edited by cubic-dev-ai Bot

Loading

cubic-dev-ai Bot left a comment •

edited

Loading

cubic-dev-ai Bot left a comment •

edited

Loading

cubic-dev-ai Bot left a comment •

edited

Loading

Mattias-Sehlstedt commented Jul 16, 2026 •

edited

Loading